An item on the editorial calendar can be a helpful guideline, or it can be the cover to Pandora's box. Take, for example, the stated topicfor this month's Focus Report: Verification. Certainly it's an important topic. It's even arguable that verification is emerging as a discipline distinct from design -- take a look, for example, at Janick Bergeron's Verification Guild, at http://www.janick.bergeron.com.

But writing an article on ''verification' 'would be about like doing 1,000 words on, say, ''biology.'' You have to narrow the field a little bit or you won't be able to say anything. So I chose to focus on one particular aspect of verification, the role played by programmable logic.

This was an easy enough topic to pursue. As you can see from the Focus (page 60), there is a wide range of vendors of verification tools, from very simple boards to enormous ASIC emulation systems. All of the tools depend on programmable logic in one way or another,and all of the vendors are delighted to discuss their products with the press.

The fragment of data that is too easy to overlook is that many design teams do at least some verification on PLDs without the aid of any of those vendors. They take the most time-honored of approaches: they implement the design in programmable logic concurrently with their ASIC design.

That approach has its strengths and weaknesses, of course. It demands little front-end investment or management authorization, can be started quickly, often using off-the-shelf boards to help with the build process, and can result in prototypes of enormous value not only in verification, but to the software developers as well. On the darker side, the FPGA design can become a millstone around the team's neck, even though as a verification tool it is usually relieved of the need for real-time performance. And once the FPGA design is done, the verification tools available to see how it behaves may be less than exciting.

But it may be that using FPGAs in verification is meeting an emotional need rather than a logical one. Try this hypothesis. Since the appearance of effective HDLs, there have been two kinds of chip designers in the world: those who see design as building something tangible, and those who see design as a linguistic exercise. For the tangible types, there is no substitute for actually implementing a design in silicon and seeing it do stuff, even if you don't find any new bugs. For the linguistic types, the only value to a PLD implementation is that it gets through the verification suite faster.

Like so many other things, though,the optimum in verification is a harmonic blend of those points of view. Cut'n'try is reassuring. But these days, it may take the whole first half of an ASIC flow just to get to the point where you can start designing the FPGAs. And formal verification tools may be needed as well. For example, one of the gaps in current PLD-assisted methodology is a formal proof of equivalence between the logic-cell program that ends up in the PLD and the RTL or gate-level ASIC design that's being verified. They are, after all, very different implementations.